Forum:Setting Table
Instead of writing the long string of codes for our tables, I'd like to use the "table" class, and the game series class codes as well. Also, this means getting a consistent look for the tables just like we did for the infoboxes. Compared to the table that uses the "customtable" class: with the one that uses the "table" class: It improves readability especially when links are inside the main row. This also means we can reduce the use of hacks using style codes. For the time being, the table class will bold the words in the main row. That's until I can figure out how to achieve: just by stringing: The customtable class isn't horrible, but the design didn't consider having links in the main row. The table class didn't consider the main row being used for prose and simple lists. The CSS has been heavily edited to include the customized table styles but it needs to be standardized from now on. The table format should consider: *having wikilinks which colors didn't fit with the class codes. *using the ! to automatically create headers *use the class codes as appropriate. *being flexible for use in different formats like stats and lists. Thoughts? BLUER一番 12:33, June 14, 2013 (UTC) :I admit, I know all of nothing about code or tables or the like, but yes, the table format looks much better, though the "things in first column are automatically bolded and put on a black background" can be problematic for things like skill lists and such. I will be honest, I don't consciously use the customtable, I just kinda use the one that similar pages are using.--Otherarrow (talk) 15:16, June 14, 2013 (UTC) ::I know it is possible to use a game header color like #4372AA for P3 tables, and when we use "!" it uses a normal header. The code has eluded me for some time though. Tried asking Inpursuit but he's under the opinion that it is not possible. I saw some wikis were able to do it, but looking at their CSS it didn't make enough sense. BLUER一番 16:26, June 15, 2013 (UTC) Update 1 I was going to set up the Help Page but since our point of contention is the automatic first data column highlight, we could decide on the better approach that would reduce the use of hacks on the tables. I have two proposals for the community to consider: 1. Remove the automatic first data column highlight from the "table" class and place it into the "customtable" class, renaming that class ie "tablehighlight" etc. This way, we will have two class of tables but the main one will be usable for everything else like skill lists. 2. Remove the automatic first data column highlight from the "table" class and create a class coding for highlighting data cells in the table ie "tr > td.highlight {background:#111111; font-weight:bold;}", and remove the "customtable" class. To use it, the editor will have to write |class="highlight"|subject on every data cell. Can we have a vote or any third options to consider? BLUER一番 02:48, August 13, 2013 (UTC) :I don't understand why we have to eliminate one of the table Classes, both are useful for different occasions with minimal hack on the table code by the end editor. -- Inpursuit (talk) 03:01, August 13, 2013 (UTC) ::It's not eliminating per se, but rather switching it between functions. "Customtable" becomes the default "table" class, while the highlighted column table class is renamed. ::We could just go with the status quo now. We'll still need to go over each article that uses a table and switch those tables over with the class codes. BLUER一番 03:17, August 13, 2013 (UTC) :::My main concern is that if there's any tool can trace back which article has applied which table class. There is no search result of (list of demon) article by either Wikia build in search engine or Google because the keyword "customtable" is not the textual content in the article but a styling code which is intentionally omitted in most search criteria. If it's possible to trace back the usage of a particular table class, then it's perfectly fine to replace the class style however you want. If no then not even a bot would be helpful because of the shortcoming of the search result which either bot or human editor are relied on. -- Inpursuit (talk) 03:33, August 13, 2013 (UTC)